Tech Arsenal 1

home *** CD-ROM | disk | FTP | other *** search

/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-06 / an008a.zip / AN008A.TXT < prev

Wrap

Text File | 1991-02-07 | 50KB | 994 lines

MAC Layer Bridging Techniques Brian Howell Consultant Systems Engineering Division Abstract: This AppNote outlines the roles of gateways, routers and media access control (MAC) or MAC layer bridges in local area networks. Bridging techniques are compared, and the features, fuctionality and advantages of bridges are described. Disclaimer Novell, Inc. makes no representations or warranties with respect to the contents or use of these Application Notes, or any of the third-party products discussed in the AppNotes Novell reserves the right to revise these Application Notes and to make changes in their contents at any time, without obligation to notify any person or entity of such revisions or changes. These AppNotes do not constitute an endorsement of the third-party product or products that were tested. The configuration or configurations tested or described may or may not be the only available solution. Any test is not a determination of product quality or correctness, nor does it ensure compliance with any federal, state or local requirements. Novell does not warranty products except as stated in applicable Novell product warranties or license agreements. Copyright { 1990 by Novell, Inc., Provo, Utah. All rights reserved. As a means of promoting NetWare Application Notes, Novell grants you without charge the right to reproduce, distribute and use copies of the AppNotes provided you do not receive any payment, commercial benefit or other consideration for the reproduction or distribution, or change any copyright notices appearing on or in the document. Introduction As local area networks (LANs) expand to meet the needs of growing organizations and as larger organizations integrate dissimilar LANs into their existing networks, versatile tools for facilitating this expansion become necessary. Some of the tools available for connecting dissimilar LANs and facilitating network integration are gateways, routers and Media Access Control (MAC) bridges. The features and functions delineating these products are becoming more similar, causing a significant amount of confusion regarding appropriate implementation of these products. This report will clarify the roles of these tools and concentrate on the role of bridges in progressive network strategies. Gateways perform protocol conversion from at least the Network Layer of the Open Systems Interconnect (OSI) model through all of the higher layers of the OSI model. Gateways perform an active function on the LAN. In order for a workstation to establish a session with a host, the gateway has to manage the host sessions for the workstation and the host, and translate the higher layer protocols for each side of the session. Because of the high layer of processing necessary to maintain a communication session between a workstation and an attached host, gateways are generally slow, and limited to specific applications and protocols. Routers work at the Network Layer of the OSI model. Routers interpret the information in the data packet to determine the routing of the packet. Consequently, routers must understand the protocol being used and deployed in applications specific to a given protocol. Recently, routers that understand more than one protocol and rival the versatility of bridges have been introduced. Perhaps the most versatile tool available for interconnecting dissimilar LANs is the MAC Layer bridge. Bridges operate at the Media Access Control (MAC) Layer of the OSI model, which is the lower half of the Data Link Layer. Because bridges are commonly used for interconnecting LANs and because of the high layer of performance and flexibility provided by bridges, this report will focus on the features, functionality and advantages afforded by including bridges in a progressive network strategy. Open Systems Interconnection (OSI Model) Each layer of the OSI model defines a set of functions. Layers 2 through 7 are associated with software and logical functions while Layer 1 deals primarily with the physical transmission of the signals over the media. Each functional layer of the model is addressed by a piece of hardware or software on one side of the communications link that corresponds with the identical layer in the hardware or software on the other side of the link. Data is passed through each layer from Layer 7 down to Layer 1 where it is then transmitted to the other side of the link over a physical communication medium. Layer 1 of the other machine then passes the data up through its layers until it reaches Layer 7. Application Layer Layer 7 provides user services to the network. Network access, error recovery, flow control, terminal emulation, processor sharing, file transfer and remote system initiation and termination are some functions of this layer. Presentation Layer Layer 6 performs message transformation and formatting such as data unpacking, translation, protocol conversion and the expansion of graphics commands in order to present data to the user. Session Layer Layer 5 provides for the establishment, maintenance and termination of logical sessions between two or more user connections. The Session Layer is responsible for handling session requests and response data to establish and terminate a session in an orderly manner. Transport Layer Layer 4 provides user addressing, flow control, error detection and handling, and manages problems dealing with the transmission and reception of packets. This layer also multiplexes several messages onto one physical circuit by creating multiple logical connections. Network Layer Layer 3 supports functions of internal network operations. Its routing and addressing services send data to the required destinations on the network. This layer is also responsible for controlling the operations of Layers 1 and 2. Data Link Layer Layer 2 manages the transmission circuit. Creating and recognizing frame boundaries and providing for error checking are functions of this layer. Low level flow control which allows the receiver to control the rate of sending to prevent buffer overflow is also performed at this layer. The Data Link Layer is divided into two sublayers. The upper sublayer is the Logical Link Control (LLC) Layer and the lower sublayer is the Media Access Control (MAC) Layer. illustrates the LLC and MAC Layer field definitions. Physical Layer Layer 1 deals with the physical, electrical and mechanical network connections. Transmission speeds, modulation techniques and transmission frequencies that the network implements are determined at this layer. All data must be passed down to Layer 1 in order to have communications between nodes. Repeaters Repeaters connect two similar LANs and extend LAN distances (see below). Operating at the Physical Layer, repeaters require the media and protocol of the two connected LANs to be the same, and offer no protocol conversion. Their function is to repeat signals received from one LAN to another. Repeaters amplify, reshape and re-time incoming signals that have become weak and distorted, and transmit them to another LAN segment. Application Application Presentation Presentation Session Session Transport Transport Network Network Data Link Data Link Physical <------------> Physical Bridges Bridges are protocol-independent devices that connect both similar and dissimilar LANs (see below). Bridges operate at the MAC sublayer. They contain intelligence to perform data packet filtering, media protocol conversion and repeater functions. Bridges discern which packets should be passed on to another LAN and which should stay within their originating network. The packets are not interpreted, but the MAC destination and source address of each data packet is monitored. Two bridged networks that do not share the same upper-layer protocols are still able to exchange packets. Application Application Presentation Presentation Session Session Transport Transport Network Network Data Link <------------> Data Link Physical <------------> Physical Routers Routers are protocol-dependent devices that connect LANs at the Network Layer (see below). Routers monitor the data packet information to decide which data packets to keep and which ones to transfer. Routers are able to pass only protocols they understand. Newer routers handle more than one protocol at a time. Application <------------> Application Presentation <------------> Presentation Session <------------> Session Transport <------------> Transport Network <------------> Network Data Link <------------> Data Link Physical <------------> Physical Gateways Gateways provide communication access between two environments which use different protocols (see below). A network running DECnet can communicate through a gateway with a network running SNA. Gateways perform protocol translation for all seven layers as well as performing all the functions of a router. They generally provide slower response times than bridges and routers, have limited performance and their functions are so specialized their use is limited to particular applications. Application <------------> Application Presentation <------------> Presentation Session <------------> Session Transport <------------> Transport Network <------------> Network Data Link <------------> Data Link Physical <------------> Physical Protocol Converters Protocol converters translate one communications protocol into another (see below). They are used to connect two otherwise incompatible communications devices. A protocol converter can, for instance, convert an asynchronous protocol to SNA/SDLC which is synchronous. This would cause an asynchronous device to appear as an SNA/SDLC device to the connected mainframe. Application <------------> Application Presentation <------------> Presentation Session <------------> Session Transport <------------> Transport Network <------------> Network Data Link <------------> Data Link Physical <------------> Physical MAC Layer Bridging illustrates the characteristics inherent in the MAC Layer frame format that allow for multiple Network Layer protocols to be transported via MAC Layer bridges. Since the bridge makes the filter or forward decision based upon the destination and source addresses of the packet, it must only examine the first few fields of the frame. Since most of the bridges also make decisions based on the type of packet that is being sent, they also examine the type field, which indicates what upper layer protocol is being used. By examining these three fields, the bridge gains enough information about the sender, the receiver and the protocol being used to provide a significant amount of functionality to the user. The bridges will forward the packet on its way regardless of the upper layer protocol being used unless the user has specified that the bridge is to take special action regarding a particular packet type or address. (See section on Programmable Filtering and Routing.) also shows the differences between the MAC Layer frame formats for the most commonly used access methods. Note especially the differences between 802.3 frames and 802.5 frames. The only real points they have in common are the source and destination address field lengths, that they both have an information field and that they both have some means of delineating the beginning and the end of the frame. The differences between frame formats are what make the development of interconnection products for 802.5 networks and 802.3 networks so difficult. (See SRT Bridges.) Media Conversion One function that bridges may perform is the conversion from one physical medium to another. This feature is extremely useful when small workgroup LANs are connected to a high-speed backbone or to remote LANs. For instance, workgroup LANs may be on twisted pair or thin Ethernet cabling, and the backbone may be fiber optic or thick Ethernet. In this case, the bridge handles the conversion from one medium to another. This ability to convert one media to another also makes possible the remote connection of geographically distant LANs. In the case of remote networks where a bridge is attached to a digital link or some other WAN transport medium, the bridge converts the signal from the LAN adapter into a signal that can be transmitted on the WAN link. Distance Limitations The type of cabling used in a LAN is called the medium. Every medium is limited by how fast and how far it can carry the signals that make up data traffic before the signals become so weak and distorted that the receiving end cannot understand the signal it receives. For example, standard Ethernet (IEEE 802.3 10Base5, ISO 8802-3) and thin Ethernet (IEEE 802.3 10base2, ISO 8802-3) both use the same bit rates. But because of the higher attenuation layer of thin Ethernet cabling, its distance limitation is 200 meters compared to thick Ethernet cabling's limitation of 500 meters. : ANSI/IEEE Standards Note: n represents an integer value equal to or greater than zero. By regenerating the signals they receive, bridges extend the reach of LANs. They act as repeaters which take a signal from the physical medium and regenerate it before they send it out to the next segment. This technique avoids the problem of media distance limitations. However, performance expectations and timeout requirements of upper layer protocols and applications must be considered when bridges are used this way. Auto-learning and Configuration Most bridges listen to the network and set up an address table based on the source and destination addresses of the packets they receive. Since the bridges know which LAN segment a packet came in on, they can determine whether the destination address is local or remote. After monitoring the network for several minutes, the bridge builds a table of the network nodes actively sending and receiving information. The automatic learning and configuration process is taken one step further by bridges implementing the Spanning Tree Protocol (STP). All of the bridges on the network use the STP algorithm to determine which bridge is the root bridge and eliminate loops as dictated by the 802.1D IEEE specification. (See Spanning Tree Protocol.) Programmable Filtering and Routing Filtering Capabilities Almost all high-end bridges available today have some filtering capabilities. There is a spectrum of filtering capabilities ranging from basic source and destination address filtering to sophisticated pattern match filters. Some of the bridges allow for filters to be configured or changed on the fly while others require the bridges to be rebooted to make configuration changes. Almost all of the bridges allow some sort of checking of the source and destination address fields and the packet type field. The destination address can be filtered based on whether it is destined for a single station (individual address), a group of stations (multicast) or all stations (broadcast). Retix bridges allow for filters that include a range of addresses to be set up. When this is done, the network manager can put in a number of addresses at once. Filtering on the packet type field allows different protocols to either be filtered out or given higher priority for faster transmission across a slow communications link. Filtering on the packet type field also enables the routing of certain protocols. Bridges with routing capabilities (Brouters) use this feature to selectively route flagged packets. Vitalink bridges provide sophisticated filtering capabilities that include the previously described fields and custom bit pattern match filtering. This enables the bridge to filter packets based on virtually any user- defined, six-byte pattern. Halley Systems' bridges give the network manager the capability of filtering on 10 masks made up of three 16-bit fields. Once the bridge uses a preset filter to recognize a match, there are a variety of options regarding what can be done with the packets. Most of the bridges provide for filtering (discarding) or forwarding the packet based on the preconfigurations. Vitalink bridges can be configured to discard, forward, count or prioritize packets based on the filtering criteria. Security By using the various filtering techniques and other security features available in bridges, another layer of security can be added to protect access to sensitive data. For example, the network manager may want to limit access to a file server used exclusively for payroll information. In addition to filtering masks, Halley for example, provides a management facility enabling the network manager to set an access in and an access out value from 1 to 15 for each node on the network. For a node to access another node, the sending node's access out value must be equal to or greater than the access value of the receiving node. By implementing filters to discard packets sent from unauthorized stations, the bridges add additional security that aids in safeguarding important information. Traffic Partitioning Bridges were also developed to segment heavily loaded networks. By segmenting the traffic, better performance is achieved. Troubleshooting LAN problems is easier when the network is broken into several manageable subnets. Localizing traffic localized the problems, thereby limiting the number of users who were affected by remote network problems. The first bridges were local only and accommodated only one access method and medium. Linking LANs Bridges can be local or remote. Local bridges connect LANs in the same physical location. Remote bridges are connected via some type of transmission facility. They are used to connect geographically dispersed LANs. Bridges are available that have a wide variety of communications interfaces including RS-232C for lower speeds, and V.35 or RS422 for higher speeds, including T1 at 1.54 Mbit/s and European T1 at 2.048 Mbit/s. Broadband, fiber optic, infrared, microwave and satellite transmission capabilities are also available. The bridge has the responsibility of filtering the traffic from the LAN network adapter, and reformatting, buffering and forwarding the traffic destined for the remote LAN. Most bridges implement some kind of data compression technique to maximize the efficiency of the communications link. They also generally implement some type of proprietary protocol across the link. This protocol is responsible for error checking and retransmitting of bad or incomplete packets. The standards committee is considering moving to a standard point-to-point protocol (PPP) that would provide for a bridge from a particular vendor to communicate with the bridges from any other vendor because of sharing a common protocol across the communications link. Users could then mix and match bridges to satisfy their networking requirements. Performance Expectations When implementing bridge technology you should consider the performance difference introduced when link speeds are significantly reduced. The response time to complete an application operation over a remote bridge is significantly longer than that required on a local LAN segment. Table I illustrates the time for a 640KB application to load at the respective link speeds listed. The tests assume 100 percent efficiency (no errors or retransmissions). Table I: Loading time Source: Cryptall Communication Corporation, Remote LAN/WAN Networking Guide Since high performance is usually associated with high costs, the network engineer has to weigh the potential performance benefits of a higher link speed against the greater costs of the high-speed links. Some banking or financial applications are extremely time-sensitive and require interactive transactions. In these cases, the cost of a high-speed link may be justified since the delay of a few minutes can cost the user a great amount of money. For the manufacturing plant that sends daily production information to a corporate mainframe, the cost of a high-speed link may not be justified. Bandwidth-Saving Techniques You can use certain techniques to maximize your available bandwidth. First, load the application from a local drive or a server on a LAN (not across a WAN link). Second, if interactive traffic is required, design the application so only screen updates and keyboard input are sent across the link. Third, make large file transfers during off hours when the interactive traffic is at a minimum. By implementing some of these bandwidth-saving techniques, the WAN link can be used to its maximum while still providing additional connectivity inherent in the WAN. Spanning Tree Protocol vs. Source Routing Spanning Tree Protocol The spanning tree protocol (STP) allows multiple or redundant paths between 802.3 LANs without violating the specification. Since the 802.3 specification forbids loops in an internetwork topology, the spanning tree algorithm provides a way to determine a single path of bridges and LANs between any two nodes in the network. In order for the STP algorithm to work, each bridge must have a unique identifier. Each LAN must also have a unique group address known to all the bridges on that LAN. Each port of each bridge must also be uniquely identified. All bridges on the network participate in the process of defining the STP. This process happens without human intervention. Information is exchanged between bridges by way of bridge protocol data units (BPDUs). BPDUs include information such as the identifier of the root bridge, the path cost to the root and the message age of the BPDU. Every one to four seconds the root bridge transmits BPDUs containing information such as its bridge and port identifier. A designated bridge also sends a BPDU on each of its designated ports each time it receives one on its root port. This limits the number of BPDUs to less than or equal to the number of BPDUs sent out by the root bridge. (See .) To start the process, a root bridge is chosen based on the value of the unique identifier associated with each bridge. The identifier is made up of a priority field and a secondary field designed to provide uniqueness. The root bridge is the bridge that has the best priority. If two bridges have the same priority, then a root is chosen based on the value of its secondary field. Once the root bridge is selected, each of the bridges determines which of its ports is closest to the root bridge (the port with the least-cost path to the root.) Path costs are computed by taking the inverse of the port speed in bit/s. In other words, the highest- speed link will have the lowest-path-cost value. Each of the bridges determines its path cost by dividing the port speed in question into 100 million. 100 million is defined as the highest-speed network because of compatibility issues with the 802.1 MAC bridge specification. For example, the path cost for a 10 Mbit 802.3 LAN would be 10. By this process the least-cost path to the root is found and a bridge is defined as the designated bridge for each LAN. By participating in this election process, each bridge will eventually place its root port and all ports connected to LANs for which it is the designated bridge into a forwarding state. All other ports are placed into a blocking state. Bridges that have ports in a blocking state must be able to adapt to changes in the topology and activate those ports if necessary. Only one bridge on each LAN is identified as the designated bridge and is responsible for sending BPDUs on that LAN. If a bridge ceases to send out BPDUs, the other bridges wait until the expiration of a maximum-age timer and then begin the election process to determine which of the remaining bridges will become the new designated bridge. The blocked ports then go into a listening state where BPDUs are sent and received but no station traffic is passed. After a preset timer has elapsed, the ports then are changed to a learning state which is similar to the listening state except that the information received on the port is submitted to the learning process. After the learning timer has expired, the bridge port is changed from the blocking state to the forwarding state and BPDUs are passed to update the parent bridges and the root bridge of the new configuration. The STP thus allows for redundancy to be built into a network design without violating the no loop rule of the 802.3 IEEE specification. : Spanning tree configurations The bridges described above perform their initial configuration and subsequent configuration changes transparently. Load Sharing One of the main reasons for implementing STP is that redundant parallel links can exist in the network configuration without violating the 802.3 IEEE specification. The specification purposely prohibits the formation of loops in the network topology so that packets can not be received from more than one direction by any station on the network. By placing one of two parallel links in a blocking or backup state the STP allows for redundant links to exist in the network. However, many users complained that expensive bandwidth was being wasted by sitting idle waiting for the primary link to fail. Users were subjected to lowered response time because of congested primary links being used to capacity. Some bridge vendors developed alternative means for using the idle bandwidth. Vitalink, for example, developed what they call distributed load sharing (DLS) that allows the network manager to specify a link as a backup link and as a DLS link. If a link is specified as a DLS link, it can be used by the bridges to transport traffic that is destined to go only between the two LANs and that would normally have to go across the other primary parallel link. Halley Systems Brouters implement a different type of configuration algorithm to provide for the self-learning and self-configuration of the network. Because Halley's Brouters do not use the STP and are completely table-driven, they are able to implement multiple parallel links between Brouters. These links dynamically share the traffic load between any two remotely connected LANs. The Brouters are still transparent to the users. None of the LANs know they are not directly connected to the remote network. In , traffic from LAN B destined for LAN C will have to go through Bridge A while the link between B and C sits idle in blocking mode. Traffic from LAN C destined for LAN E has to go through bridges A and F to get to E while a direct link sits idle. To avoid this situation, several bridge vendors have implemented a way for these idle or backup links to be used for traffic being passed between specific bridges while still maintaining the no loops spanning tree configuration. In the example shown, the link represented by the dashed line between B and C could be designated as a load-sharing link and would only be used for passing packets addressed for stations on LANs B or C. Source Routing Source routing is a routing mechanism currently being used on some Token- Ring networks to determine optimal paths between communicating stations. The technique works by having the source workstation send out a route determination broadcast message. This broadcast message is propagated to every interconnected ring searching for the station address identified in the destination address field of the packet. As the broadcast message is copied from ring to ring, routing information that includes the ring and bridge numbers is added to the packet. : Load sharing The two modes of route determination broadcasts are the All Routes Broadcast and the Single Route Broadcast. The All Routes Broadcast tells all bridges to copy the packet to the next ring, which results in an exponential number of packets that reach the destination station and are returned to the originating node. For this reason, the Single Route Broadcast is more commonly used. A single packet is sent out to each ring where a single designated bridge forwards a single copy of the packet to the next ring. The bridges on each ring communicate to decide which bridge is the designated bridge. When the packet reaches the destination station, the route the packet traversed may not have been the optimal route, so the receiving station sends the route determination packet back to the sender via an All Routes Broadcast. This method specifies that multiple copies of the packet are sent in only one direction on the internetwork. It results in the original source station being able to choose the optimal route available to the destination station. Since source routing stations maintain their own routing tables and insert the routing information in every packet they send, source routing bridges do not maintain any routing tables or perform any look-up functions. They base the forwarding decision on a simple pattern match function. If a bridge is included in a route, its bridge number and the ring numbers of the rings on both sides of the bridge will be included in the routing information. If any of these addresses is missing or incorrect, the bridge will not forward the packet. In order to stop endless circulation of packets around the ring, bridges check to see that the ring number of the next ring is not already included in the routing information field of the packet. If the bridge determines the packet has already passed through the next ring, it will not forward the packet to that ring. One of the characteristics of source routing is that it allows the determination of the optimal route between any two workstations on the network. This route determination process can also be a liability. Since each bridge on the network copies each of the route determination packets, the number of packets generated by a single All Routes Broadcast becomes exponential for each bridge that is traversed. Since the routing information field allows for up to eight 2-byte route designators, at least eight rings can be traversed. shows Token-Ring packet formats. : Token-Ring packet formats The IBM Direction: Transparent Bridges and Source Routing IBM has withdrawn their proposal that source routing be accepted as the 802.1 standard. Instead they have submitted a proposal that would call for an annex to the 802.1D bridging standard that would accommodate both source routing stations and transparent bridges. The proposal specifies a source routing transparent bridge (SRT) which can handle packets from source routing stations and from transparent bridges. The SRT bridges would also allow existence of a spanning tree that would include both source routing and transparent bridging. SRTBs would function differently than the current bridge offerings that convert one packet format to another. These bridges, known as source routing transparent bridges (SRTBs), convert source routing packets to non- source routing packets to source routing packets. Some even convert from 802.3 to 802.5 and have an 802.5 adapter on one side and an 802.3 adapter on the other side. The software converts the packets from one format to another but still requires one domain for source routing and another domain for transparent bridging. A domain is an internetwork where one type of bridge is used exclusively. The SRTB does away with multiple domains by examining the routing information (RI) indicator to determine which packets are using source routing or transparent bridging. Source routing stations change the RI indicator to one, while transparent bridges leave it unchanged at zero. This difference allows the SRTB to determine whether the packet is to be transparently bridged or source routed. This proposal could be very meaningful for the future of bridging technology. It could end the source routing/spanning tree dispute and allow the best of both worlds in the same network. It would allow source routing stations and transparent bridges to coexist and share information without the costly process of converting the packets from one format to the other. Testing The following tests were designed to show the relative performance of selected bridge products. The vendors represented in the tests were randomly selected to demonstrate a cross section of bridge manufacturers and products. The tests were designed to show the kind of performance that could be expected from these products in the specific test scenarios depicted. They should not be considered comprehensive. All of the bridges were tested at 64 kbit/s since 64 kbit/s is one of the most commonly used link speeds and because all of the bridges tested supported this speed. Application Throughput Test (Perform2) illustrates the test configuration used during the application throughput test. is a graph that shows the aggregate number of kbyte/s generated for each of five bridges tested. : Test configuration for application throughput test : Application throughput graph Explanation The graph in illustrates the application data handled for the workstation through the bridge. The test measures the amount of data passed from the workstation to the file server. The measurement does not include overhead. Only Application Layer data was counted. This graph does not reflect raw bandwidth, but rather information the user would see as application information. The operation performed was an overlaid write of a 4,096 byte record. Since the record is too large to be written in one write, it was broken into smaller-sized packets to be transported across the network. Each workstation counts the number of kbyte/s of data transmitted to the file server and back, and gives a numeric value indicating the aggregate and the average. Throughput Test Conclusions There is virtually no incremental increase in the aggregate number of kbyte/s moving across the bridges because of additional traffic from the third workstation. This indicates the bridges transfer the maximum amount of traffic the link will hold. The difference in the traffic transferred by each set of bridges reflects how efficiently each set of bridges uses the bandwidth available. Traffic Forwarding Test (NetWare IPXload) illustrates the test configuration used to test the bidirectional traffic forwarding capabilities of the bridges. is a graph showing the bidirectional forwarding capabilities of the bridges using 1,054-byte packets. is a graph showing the results of the same test using 31-byte packets. : Test Configuration-Traffic Forwarding : Bidirectional traffic with 1,054-byte packets Explanation The purpose of this test was to eliminate the file server as a possible bottleneck in the testing procedure. In the previous test showing application throughput, all traffic was sent to the file server and back. In this test, each of the workstations was running an application that sent packets to a target workstation as fast as the hardware would allow with no expectation of a response. The application counted how many packets were sent and received. Even though each workstation was sending and receiving packets, the file server was doing no work. Half of the workstations were on one side of the bridges, the other half were on the opposite side of the bridges. Each workstation was instructed to send packets to a specific workstation's address on the opposite side of the bridges. The test was performed with two packet sizes to illustrate how packet size could impact performance. Forwarding Test Conclusions Note: The application used in this test was specially designed to send the maximum number of packets across the available link and saturate the link with the least number of workstations possible. The results of this test have no similarity to real-world application loads. When this test was performed with large packets, the performance closely followed that of the application throughput test. When the fifth and sixth workstations were added, a noticeable delay was encountered as some of the workstations sat idle, waiting to send their packets. However, when smaller packets were used, it took only four workstations to saturate the communications link and cause the bridges to discard packets that could not be forwarded. This result occurs because the bridge has the same amount of work to do regardless of the packet size. When the packets are small, the bridge has less time between packets to accomplish its functions. The amount of time the bridge has to process the packet depends on the length of the packet and the amount of time between packets. In a real- world environment, the time between packets cannot be kept constant because many workstations will be sending traffic at sporadic intervals. The size of the packets also cannot be kept constant, because different applications and operations within a given application will generate different sized packets. For this test, a fixed packet size was used in both tests. When more than one workstation is used to generate traffic, it is impossible to control the interval between packets due to possible collisions and retransmissions. The numbers represented in show the amount of data that was forwarded by the bridge across a simulated 64 kbit/s link. In every case, the number of packets sent was greater than the number of packets received, indicating that the bridges had to discard packets because their buffers were full. Using 31-byte packets under these extreme conditions put such a strain on the bridges, and filled the buffers so quickly, that access to the communications link was delayed and the application timed out. When communications are this congested, applications do not operate normally. Network Test Battery (Master Test) The test configuration for the following tests is the same as shown in . shows the graph for each of five bridges tested for the following: o Random Directory Search o Directory Search (*.*) o Record Lock/Unlock o Private File 128KB Random Read o Large Shared File Random Read o Small Shared File Random Read o Open/Close File-Single Directory o Open/Close File-Multiple Directory Explanation The graph in illustrates the relative performance of five bridges when performing eight common LAN operations. The tests were run three times. The average of the three test runs is shown. The tests were run from a workstation on the opposite side of the bridges from the file server. A second workstation monitored the results of the tests and counted the operations per second completed by the workstation performing the operation. Test Battery Conclusions Because of the way the bridges manage the communications link, some bridges handle certain operations better than others. For example, bridge 1 provided the workstations with a slightly higher level of access in six of the eight operations, but bridge 2 provided extremely good access for the other two operations. These small discrepancies are due to the differences in the way each bridge filters and forwards packets for given operations. Conclusion Bridging technology has made significant advances within the last few years. A significant networking role exists for bridging due to the versatility and high level of functionality that exists in the products today. The filtering capabilities that are now available in bridges allow the bridges to rival the functionality of multiprotocol routers. Some protocols such as LAT cannot be routed and must be bridged. Network design characteristics inherent in bridges such as increased network performance and manageability make bridges viable networking tools for implementing multiprotocol and multiple topology networks. Appendix A: Participating Bridge Vendors The bridge vendors who graciously loaned us thousands of dollars worth of products for our tests are listed below in alphabetical order. Vendor Product CrossComm Corp. ILAN-1 133 E. Main St. Marlborough, MA 01752 Halley Systems, Inc. Connect LAN 100 2730 Orchard Parkway v2.11 San Jose, CA 95134 MICROCOM MLB 2000 1400 Providence Highway Norwood, MA 02062 Retix 4880 High Performance 2644 30th Street Remote LAN Bridge Santa Monica, CA 90405-3009 Vitalink Communications Corporation TransLAN 320 1350 Charleston Road Mt. View, CA 94043 Appendix B: Test Descriptions Network Test Battery The network test battery is a utility developed by Novell for benchmarking and network performance measuring. The battery consists of a series of commonly performed network operations. The name of each test describes the operation being performed. Each of the operations was performed for a duration of 20 seconds except for the directory search tests, which were performed for a duration of 10 seconds each. The numeric value obtained from the tests indicates the number of operations per second that could be performed within the time frame of the test duration. Each of the individual tests is described in more detail below. 1. Open/Close File (multiple directories) (no disk activity): This test measures the number of file opens and closes the file server can perform per second. The files to be opened are selected randomly within the four levels of subdirectories. Besides testing the speed at which the file server can do an open and close, this test also measures the time it takes the server to traverse the hierarchical directory structure. 2. Open/Close File (single directory) (no disk activity): This test is the same as test 1, except that the files being opened are confined to the highest-level directory. Comparing the results of this test with test 1 illustrates the difference that traversing the hierarchical directory structure makes. This test focuses more on raw file open and close speeds. 3. Small Shared File Random Read (4KB) (no disk activity): This test provides a measure of the software time required to perform disk read operations, excluding managing the disk channel. The requests are only for one byte of data, to minimize the packet size and the transfer time between the file server and network adapter. The file is shared so that the workstation PC cannot do local buffering and must access the file server for every request. This test is the best measurement of the time it takes the operating system software to service a read request. As such, it is a measurement of software efficiency, excluding as much as possible the hardware I/O factor. Disk read is the most common file server request made. 4. Large Shared File Random Read (4MB) (requires disk activity): This test measures the time it takes to randomly read a large database-type file. The requests are only for one byte of data, again to minimize the packet size and the transfer time between the file server and network adapter. Since the file is so large, only parts of it can be cached in the server RAM, and each request probably has to go to the hard disk. 5. Private File Random Read (128KB) (requires disk activity): This test illustrates the problems of local caching by the PC. A private file is randomly read 64 bytes at a time. The MS Net- based operating systems will read more than 64 bytes around the request and cache it locally. However, the effort spent servicing the larger read will be wasted because the file accessing is random and extra data read probably will not be needed. 6. Record Lock/Unlock (no disk activity): This benchmark tests the speed in which the file server can lock and unlock records. A single physical record is locked and unlocked by the workstation. 7. Directory Search Test (no disk activity): This test measures the number of wildcard directory searches the file server can perform per second. A search request can return several matching directory entries. The next search does not have to make a request to the file server. NetWare does not return multiple directory entries per search request and does not cache directory entries in the local workstations. 8. Random Directory Search (multiple directories) (no disk activity): This test shows the speed in which a search for a specific directory entry can be performed. The test selects a random file within one of the four directory entries and searches for it. It also randomly selects files that do not exist to measure the time it takes to find out that a file is not there. Perform2 Test The Perform2 test is a test designed by Novell to measure true data throughput or performance of a network. This test is completely end-to-end at the application layer of the OSI model. The test is an application that sends data to the file server and back as fast as the hardware will allow. The numeric value is a measure of the actual data throughput listed in kbyte/s. This is not intended to be a measure of raw bandwidth or transmission capability, but more specifically, data throughput capability as seen by a network user using a network application. The actual operation performed by the test consisted of data writes of records 4,096 bytes long. The writes were performed in overlaid fashion (each record was written on top of the previous record). The test was run until 100 iterations had been written. Selected Bibliography Books ANSI/IEEE Standard, 802.2 (Draft International Standard), Logical Link Control. IEEE, Inc. 1984. . 802.3 (Draft International Standard), Carrier Sense Multiple Access with Collision Detection. IEEE, Inc. 1985. . 802.5 (ISO Draft Proposal), Token-Ring Access Method. IEEE, Inc. 1985. Token-Ring Network, Architecture Reference. IBM 1986, 1987. Articles Backes, Floyd. Transparent Bridges for Interconnection of IEEE 802 LANs. IEEE Network Magazine. (January 1988): 5-9. Dixon, Roy C. and Pitt, Daniel A. Addressing, Bridging, and Source Routing. IEEE Network Magazine. (January 1988): 33-36. Cargill, Carl and Soha, Michael. Standards and Their Influence on MAC Bridges. IEEE Network Magazine. (January 1988): 87-89. IEEE Network Magazine. (January 1988). Greenfield, David M. An End to a Bridging Feud? Data Communications. (May 1990): Page 49. Hart, John. Extending the IEEE 802.1 MAC Bridge Standard to Remote Bridges. IEEE Network Magazine. (January 1988): 10-15. Hinden, Eric M. Ethernet to Token-Ring: The Gap Begins to Narrow. Data Communications. (April 1989): 48-50. Mandroc, Bob. Designing Spanning Tree Networks with Distributed Load Sharing. Vitalink Communications Corporation. (June 1988). Retix Local Bridge Application Guide. Retix, 1989. Richert, Joseph B. Jr. Evaluating MAC Layer Bridges-Beyond Filtering and Forwarding. Data Communications. (May 1990): Page 117. Schnaidt, Patricia. Span the LAN-Linking LANs with MAC Layer Bridges. LAN Magazine. (February 1988): 28-32. Sincoskie, David, W. and Cotton, Charles, J. Extended Bridge Algorithms for Large Networks. IEEE Network Magazine. (January 1988): 16-24. Soha, Michael and Perlman, Radia. Comparison of Two LAN Bridge Approaches. IEEE Network Magazine. (January 1988): 36-43. Spanning Tree Protocol on MAC Layer Bridges. Linkage, Advanced Computer Communications, 1988. Weiss, Jeffery. Remote LAN/WAN Networking Guide. Cryptall Communications Corporation, 1987. Witkowicz, Tad. Connecting LANs. Differentiating Gateways, Bridges, Routers, Repeaters. LAN Magazine. (February 1988): 34-37. Zhang, Lixia. Comparison of Two Bridge Routing Approaches. IEEE Network Magazine. (January 1988): 44-48.